A Suggesited Model 
For 

Development of 
Computer Assisted Instruction 

For 

Hi gher Educat i an 



ED 




o^Affrmnr Of cowCATio«j 

NATIONAL tNSTlTUTE OF EDUCATION 

^ CENTEH ilBiCl 

Mmnr ^h^qn^ f^*^** f^^**" ''^ '"^''^ 



■ pEftMtSStON to REPRODUCE THIS 
MATCfllAt HAS efiEN GRANTED BY 



_j^2u^ 



TO THE EDUCATIONAt RESOURCES 
INFORMMtON CENTER iERtC) ' 



By 

Terry Dixon 
October 11, 1984 



A Suggested Model 
For 

Devel opment of 
Computer Assisted Instruction 

For 

Higher Education 



ilS. M^MrnvCNT Of tPUCAltOM 

NATIOMAL MVSTfTUT£ OP £OUCATIOW 

eOl^TlONAL fttSOUftCtS iMFOHWATfOty 

r*H:#«ve() fumi the (scfson of Qc^irw/ation 
4 If t^rnatifig it 

Mmw t^^w^cjtt* ht*vi* t»*?^A nvnttj MTiyittivr 



■PEflMISSlON TO RKPRODUCE iHib 
MATefWAL HAS BEEN GRANTfcD SY 



TO THE eOUCATlONAL RESOURCtS 
JNFOflMATtON CeNTER (ER(C! ' 



By 

Terry Dixon 
October 11, 19S4 



Introduct i on 



The nil crocomputer is a powerful tool capabl © of many 
thi ngB which can benef it the instruct ional process. Mhen 
chosen to be used to communicate or teach the appropriate 
objectives through Computer Assisted Instruction, it becomes 
a powerful tool f one which offers characteristics 
unsurpassed by other media tools. The power of the 
Microcomputer , as an i nstructi onal tool 9 comes from six 
basic features. These include the ability to; analyze and 
prescribe (systematize) ; provide active involvement in 
learning? allow the student to pace the instruction; provide 
exploration cf time and space; free teachers for human and 
personal work? pr ovi de i nstructi on at a cost ef f ecti ve 
level p To summarize, this means the power of the computer 
comes from the fact it is possible to i ndi vidua 1 ize 
instruction to the nth degree , i * e, it is possibl e to 
evaluate each and every student response i n detai 1 , then 
al ter f ol 1 owing i nstructi on to best fit the particular 
student' s needs, whether it be a change in method of 
presentati on, or progressi on through the 1 esson« 
Unfortunately the very character! st ics which provides the 
powerful potential for CAI, also poses a problem* How do you 
aquire quality software which is objective specific to a 
particular classroom teachers needs? 

One would think it possible to purchase such software 
from the var i ous educat i onal mater i al supply compani es, and 
indeed it is possible to purchase a large variety of CAI 
software. However, the software available is usually very 
g*9neral in nature and its quality is usually questionable. 
As Ufilliam Montaque stated in his paper presentation at the 
1982 annual meet i ng of The American Educat i onal Research 
Assoc i at i on, "The most i nterest i ng and potent i al ly important 
thing*=> a comp^(ter can do are seldom utilisied-** If quality^^ 
objective specific software is hard or impossible to find, 
then what option is left for the teacher who desires to 
incorporate and take advantage of the potenti al of 
microcomputer instruction? 

The purpose of this response is to provide one such 
option, a model for CAI development for the classroom 
teacher*. It would be foolish to think all teachers desire* 
or have the capaci ty to design thei r own CAI sof tw^^re* 
However by provi di ng a model whi ch encourages the 
devel opment of local , ef f ecti ve and educati onal 1 y sound 
software, perhaps the quality and quantity of CAI software 
wi 1 1 increase* 

Because of the cl assroom teacher " s 1 i mi ted t i me it is 
necessary to keep the model as simple as possible, and yet 
include those techniqutJs and suggestions research has shown 
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to i ncrease effectiveness- This paper will attempt to 
synthesl ze a model whi ch meets these requi rements* 



Need 



Why anotner model for CAI development? The Association 
for Edacat i onal Communi cat i ons and Technology identi f ied 
four i ssues rel ated to the devel opment of software 
technology* These included? a lack ai adequate theory base 
supporting the di scipl i ne of i n struct i onal technology; too 
1 imi t i ng and narrow def i ni tion of the f i eld; a lack of 
courage among i net rue ti onal technol ogi es to stand up and 
take a strong position influencing the future of training 
and i nstruct i on; and, i nadequate model s which are too 
unsophisticated to be viewed as analogs for designing 
qual i ty software systems* (De Bl oois, 1982> . This suggest 
the need for CAI design models which are usableg, incorporate 
sound instructional theories and from which more models with 
further improvements can be developed. It also suggest CAt 
software devel opment should be viewed as evolutonary, no 
model being finals but simply one of a series of models, 
which allows designers to get closer to perfection, and to 
Bhare knowledge i n the technologies of other software 
designers who may brxng expertise from various other areas* 



Martin and Davi s state: 



"We must pass through a peri od in which the new inedi um 
befuddles us, in which it is applied intuitively to 
f ami 1 i ar tasks and ways of doi ng thi ngs* The 
educati onal computer i s doomed, i n other words, to 
spend some time imi tat i ng teachers and book© and, 
because the copy is never as good as the original, to 
do their tasks less effectively*" (Martin Davis, 
1983) . 



This would clearly indicate a need to go beyond the 
traditional paradigm and begin to explore the new attributes 
which the cooiputer br i ngs to i nstruct i on • Before the 
devel opment of the computer and CAI it was not feasible to 
individualize instruction to the extent possible now. yet as 
we take a close look at the software on the market we find 
-few. if any^ taking advantage of this computer attribute* 
This is probably accounted for by the fact CAI software, as 
Robert Burke* states in his CO[I Sourcebook <19S2)i 



is a very complex thing to produce, since several 
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highly sophisticated technologies must be integrated in 
such a way as to produce an organically complete entity 
which is capable of achieving a specific result. The 
CAI author must draw upon several fields of knowledge 
to put together an effective lesson^'* 



It would take a book, and indeed many have been written^ to 
include a study of all of the variables associated with 
successful CAI. Abraham Koplan sates in the text^i The 
Conduct of Inquiry:Methodology for Behavioral Sciences 



"Models never include al 1 possible elements of a 
process, but are selective. A model generally includes 
those elements which seem to occur with the process in 
ways which fit the particular situation being 
examined* " (Koplan, 1964) 



It is not the purpose of this response to provide such a 
book* It is the purpose of this response to synthesize, 
through a survey of research and readings, as wel 1 as 
experience, a model f cr designing CAI. A model which is 
simple in design, yet rich in its incorporation of 
instructional attributes which are best suited for the 
microcomputer . 



A Suggested Model for Computer Assisted Instructional Design 



Where do models come from? Many models used in the design 
of software today have their roots deeply planted in the 
fields of engineering, whether the software to be produced 
is CAI, business software, or a video game. They have 
provi ded many techni ques val uabl e to the devel opment CAI 
models. Emphasis in these models concerns controlling the 
development of the software in such a way as to insure the 
proposed end product and to decrease the time and cost of 
producing the software. Because they provide gui des for 
qual i ty control and techni ques for i ncorporati ng **1 ater 
improvements*' during the development of software, a breif 
di^jcussion of the more common models is beneficial to the 
CAI designer. 



Qomfngii Software Pgjgigns Mg^eL^ 



ChLU in his text ^ Software ifly^Br int and gy^amgl^es , 
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flientions several of the more common software design models 
found today <Chu^ 1982)- These include the Composite or 
Structural Design Model, the Jackson Model the WETA Stepwise 
Refinement Model and the higher -Order Software Model. 



The Composite or Structural Design Model 

The Composite or Structural Design Model tnias described by 
G,.J, Meyers in 1973 and consists of a discussion of the 
under p i nn i ngs of a good desi gn and methods of modul e 
dt^composi tion- Since it does not include an underlying 
mathemati cal theorem it is not very appeal i ng to many 
computer scientists* Major components of the Compos i te 
Design Model are the discussions of parti tl oni ng ^ hierarchy 
and independence, as related to module design-, 



The Jackson Model 

The Jackson model , developed by M, A- Jackson i n 1976, is 
popular in England* It views a program as the means by which 
the input data are transformed into output data. The proper 
choice of the data structure of a program is supposedly to 
lead to a good design^, 



The META Stepwise Refinement Model of Design 

H, F. Ledgard, 1973, and 0. Schneidman, 1976, first 
described this method. It is based on the experience of many 
designers who beleive a better design can be acheived by 
successfully refining a simple design until the design is at 
the desired level of detail- The program is designed in 
1 evel 5 and the detai 1 s are postponed to lower level s. 

Many advanced forms of this methodol ogy have been devel aped» 
Bnd indeed this is probably the most used method of software 
desi gn- Because i t decomposes a program into digest able 
pieces it provi des the most potent i al for teacher CAX 
desi gn ■ 



The High--Order Software Model 

The Hi gher -Order software Model was initially developod and 
promoted by M- Hamilton and S- Zeldin in 1976,. It involves a 
Bet of formal laws and a specific language to assist in the 
devol opm&nt of software. It is based on a set of iams 
which explicitly def ine a hi erar chy of software control 
f 1 ow- An automated anal yzer program is avai 1 abl e whi ch 
checks the sol ut i on to the desi gn once It i s f i ni shed- i f 
written in metalanguage. It has similar qualities to PILOT^ 
a CAI author i ng program wr i t ten for cl assroom teachers - 
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From these engineering models many valuable design 
principles can be developedji and when properly incorporated 
into a CAI design models can improve their ef f ecti veness- 
However , model s are synthe^i red from basic accepted 
assumptions or principles and to understand the models it 
becomes necessary to have a clear understanding of the basic 
principles invol ved- 

Chu describes four design principles which encourage the 
design of "good" software. These are the principles of: 
Modular i ty; Abstracti on; Local i 2 at ion ; and Hiding. 



Modular i ty 



Modularity, considered the best-known principle* is the 
decomposition of the data flow and control flow of a 
software organization into well defined modules and their 
interfaces- Modules^ according to this principle, should be 
structured in a hierachial structure to allow the designer 
to easily visualize and understand the organization. It is 
also important to have a high degree of independence from 
other modules so as to encourage a low degree of interaction 
between data and modul es. 

Modularity contributes greatly to the attainment of the 
qoal s of a program i n that it si mp 1 1 f ies understand i ng and 
reliability, since errors can be localised into modules- It 
also contributes to modi f i abi 1 i ty since a change may only 
affect a few modul es- 



Abstracti on 



Abstraction i m the removal of essent i al proper t i es, whi 1 e 
i mpl ying essenti ai detai 1 s. Each 1 evel of hierarchy 
presents an abstraction of those lower in that details are 
restricted to the lower levels^ The larger and more coniplej; 
the design^ the more valuable this principle becomes- 



Local 1 zat 1 on 



When related software elements are physically placed close 
to each other it is referred to as 1 ocal i zat i on. Avoi di ng 
the use of ^goto^ statements in a program assist in 
accofnpl I shing I ocal i zat i on , 



Mi di ng 



The hiding principle is similar to the principle of 
abstraction in that detai Is are delegated to lower level 
procedures- Al 1 detai Is of a module and its task are 
described within the module fo-" easy accessibility. Hiding 
m.3ikes the program easy to follow and customize since the 
1 nf or mat ion concerning the f uncti on and var i ables used 



Page 5 



7 



within a module are kept within each module. 



A Sugested Computer Astsisted Instructional Design Model 

The design model which follows is based an the philosophy of 
the META Stepwise Refinement Model described earlier. It 
gees from the general to the specific and is designed in 
such a way as to encourage efficiency and simplicity in 
designing CAI. The model is composed of 5 phases: Problem 
Clarification; System Design; Blueprinting; CAI Synthesis! 
and Documentation Development. Each of these phases is then 
subdivided into two or more subphaseS. 

In this particular model there are two reasons for 
dissecting the model into phases. First the phases allow 
processes which are similar in task result to be grouped 
together , thereby providing a focal point for mental 
concentration. Wi thout these logical di visions i t becomes 
difficult to keep the processes effecting each task in mind. 

The second^ and probably most important purpose of the use 
of phases, at least to classroom teachers, is that it allows 
the CAI to be developed during collections of short sittings 
over a long period of time, rather than requiring one or two 
long sessions, sessions which are not readi ly avai 1 abl e to 
the cl assroom teacher , whi 1 e at the same time not 
fe<3icr i f ici ng the quality of the software. 

Phase l: Problem Clarification 

Th^ problem Clarification Phase is composed of three 
tasks; objective development; content research, and! 
narrative synthesis. It's basic task is to verbally describe 
eNactly what the software is to accomplish, actually listing 
the e>:pected outcomes or products of the CAI program^ and to 
determine the necessary content needed to accompl i sh these 
outcomes. 

OBJECTIVE DEVELOPMENT refers to the development of the 
instructional purpose of the CAI. It is developed just as 
any other instructional objective would be developed, and 
shoul d be stated in behavioral form, incorpor ati ng the 
fct^rminal behavior e>ipected of the student, criterion for 
determining successful attainment of the terminal behavior, 
and the condi tions under whi ch the terminal behavior i s 
expected to occur. At this stage the objective would loo^: no 
di f f erent than any other ob jecti ve si nee the best method of 
i nstruct i on has not been deter mi ned ■ 

Vihen developing the obje*ctives it is important to keep the 
student population in mind and to know their abilities and 
character! sties so as to not have expectanci es of the 
students which are for any reason impossible for them to 
accomplish. or spend time developing objectives which the 
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students have al ready accompi ished * On© of the most common 
mi stakes made in CAI software devel opment today is the 
development of software for certain age and ability groups 
in a vacuum, i ^ development of sof tt^are Mi thout even 
studing the characteristics of the student population. This 
should be the strength of the teacher authored CAI ^ si nee 
this is the area of expertise the teacher brings* 

The process of objective development is the starting point 
for the development of CAIf^ and the success of the CAI can 
be no better then the objectives for which it is used^i 
therefore plenty of time should be set aside to develop 
objectives and to determine the capabilities of the student 
for any of the objectives* If careful thought is not used in 
their development many hours in the development of the CAI 
may be wasted when the author finds later the objectives are 
i nappropr i ate for the student popul at i on . It is even a good 
idea to devel ope a traditional instructional method and 
pilot test it on the student population to determine the 
appropriateness of the objectives before devoting the time 
and effort in the development of CAI* In this way objectives 
can be al tered^ added or dropped based on i nf ormat i on from 
the pilot study, before many hours are spent on the 
development of CAI to teach ihese objectives. 

Once the objective has been determined the CAI author is 
afol e to determine the general content necessary to 
accomplish the behavioral objectives* This will then suggest 
the mode of i n struct ion, i*e, tutorial, dri 11 and pract i ce*i 
simLilation J or problem solving* At this stage it is 
necessary for the CAI author to have a clear understanding 
of the characteristics of each of the computer modes of 
instruction as well as the instructional characteristics and 
c ap ac i ti es of the computer ^ otherwi se the computer may be 
ejipected to accompi i sh a task which it is physical iy 
i ncapabl e of accompi i shi ng • 

The analysing tools <pre/post*-test ) shoui d also be suggested 
by the objectives at this stage, though until the specific 
content is determined the tools should not be developed. It 
3S at this stage the de^^.c^mi nat i on of whether the computer" 
i s th<^ appropr i ate method for i nstructi on i s decided^ 
based on the behf^ivi oral obj ect i ves^ i f computers are 
d-^t ermi ned to be appropri ate^ then it may be necessary to 
dtl ter the method of anal ys i ng the success of speci f ic 
object i ves go as to t ake advanta^ge of a compute>r 
characteristic- It i'S at this point whsre the instruction 
b*^gint» to appear computer specific, i-e- the characteristics 
of the computer begin to play a part in shaping the 
i n<5tr i\c t i on, 

R^inf arcemont should also be decided at this stage, since 
the mods of instruction will hav a bearing on the method* 
f or m and appropr i ateni^ss of the rei nf orce ment to be used- 
For eK*?mpie it may be inappropriate to reinforce a drill and 
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practice with a pause in the CAI and introduction of a 
lengthy song as a reward for correctly responding to each of 
the dr i 1 1 and pr act ice problems presented, %i nee i t woul d 
interrupt the students' being on ta^k. 

With the objective development complete we have a firm 
foundation for further CAI development. The stating of the 
object i ves leads to the need for content research , 

CONTENT RESEARCH refers to the determination of what content 
is necessary to accomplish the objectives developed in stage 
Xm It al so i nvol ves dec i si on maki ng in terms of deter mi ning 
instructional time each specific piece of content is to be 
allowed in the completed CAI, 

Thi ^ stage should al so i nclude any content or i en ted 
mot i vat i on a 1 mater i al ^ i # e. any mater i al whi ch woul d gi ve 
purpose or develop the desi re of the student to want to 
accomplish the instructional objectives and content of the 
instruction. Content oriented material refers to subject 
matter , and not rei n -for cement material # For example i f your 
CAI was concerning chemistry, then you might introduce the 
instruction on the computer by stating, 'Xhemistry is 
important in all of our lives. In the 19S4 world series 
chemistry was the hero in saving the Cincinnati Reds from 
losing* As we complete this program we wi 1 1 answer the 
question how did chemistry saved the Ci nci nnati Reds from 
losing the 19S4 world series-'' 

The content research should be written as if it were a paper 
to be read or presented to the student target population* 
The emphasi s at thi s stage shoul d be on content , though 
reading ability and vocabulary should also be considered* 
The content research will become the story line of the CAI^ 
therefore it is important to write the reserach in a report 
form, as opposed to a collection of facts which have not yet 
b^e*n tied together into a story 1 ine* 

The? type of CAI used will also affect the type of content 
research whi ch is necessary* For e>i ample a dr j 1 1 and 
practice CA2 for multiplication tables will require re^e^rcU 
on the types of possible incorrect answers^ and the most 
commonl y mi ssed problemSi, so CAI t ime wi 1 1 not be 
tTiDHopol i:3ed teaching problems already learned and which can 
be controlled by the computer if we instruct it to do so* 

One e the content research has been compi eted the narrati ve 
c<\n be develoed# The narrative is a written descriptiun of 
^hat the CAI will do^ its' emphasis is on outcome. It should 
be? wri t ten as i f descr i bing the outcomes of the CAI ^ i * e* it 
=Bhould describe any product . whether i t be hardcopy, screen 
ciisp} ay or peripheral products. For example, "The math 
pr obi em generator wi 1 1 # after tak ing in the teacher 
cir i tar i ^ , produce hard copy worksheets for the studeri t rrind 
answer sheets for the teacher* '* 
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NARRATIVE DEVELOPMENT occurs once the content research has 
been completed- The narrative is a written description of 
what the CAI will do. Its^ emphasis on outcome and should 
be completely but consise and brief- It should be written ae 
i f descr ibi ng the outcomes of the CAI , i.e. it should 
describe what resources the CAI will begin with and any 
product J whether it be hardcopy* screen di spl ay or 
peripheral products which wi 11 be produced. For e>?ample, 
'*The math problem generator will, after taki ng in the 
teacher cr i ter ia^ produce hard copy worksheets lor the 
student and answer sheets for the teacher." 

The narrative does not describe the necessary processes for 
accomplishing the products, but simply describes the 
resources which wi 11 be gi ven the CAI and the product 
outcomes expected of it. This stage tells the CAI author 
when he has cofnpleted his CAI program,! so it is very 
important in terms of a mile marker. Without using the 
narrative as a mile marker the author becomes bogged down 
Into adding this or that process to make the program 
**better i nstead of to accopmpl ish the original purpose^ 
often causing author frustration. This is not to say the 
program cannot be altered along the way, but it xs to say 
the narrative can be used as a decision guide to determine 
if a new process should be added or not 

The narrative should view reinforcers as a product and for 
thi s reason the branch! ng strategy for correct and i nccjrrect 
answers, as wel 1 as the pi anned reinforcers should be 
described in this stage. Describing the branching refers to 
the general description, not the computer code. For e>iample5 
"Upon reponding correctly to the question the computer will 
di spl ay a smi 1 i ng face to i nf orm the student of a correct 
response If the student response is i ncorrect ^ the computer 
will display the phrase ** i ncorrect " ji then allow the student 
to respond once again.*' 

The narrative should be sequential in development, i ^e* 
should follow the flow of the program so as to simplify the 
s*?c:ond phase of CAI devel opment ii the System Design Phase. 

Phase n: System Design 



The purpose of System Design is to pr&parm the instruction 
for computer coding. This phase takes the narrative and 
content of the previous phase and combines it wi th the 
necessary computer requi rements so as to accompl i sh the 
e:: pec ted narrati ve. The emphasi s in thi s phase centers 
around desi gning the processes (or modul es necess^ar y to 
acL cmpl I sh the processes) necessary for the computer to 
cause the narrative to come about. The descriptions are 
g*?rierir\l in nature, but include all the necessary tashs each 
modal ^ must compl f^te* 
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The MODULARIZATION STAGE is where determination of the 
various modules necessary to accompi ish the narrative 
described in phase I is accomplished. It is accomplished by 
taking the narrative and dividing it into large system 
modules which accompl ish the various tasks necessary to 
accompl ish the narravi tve* Thi is accompl i shed by 
physi cal 1 y drawing bo>:es around each 1 ogical di vi si on of 
processes described in the narrative. At this stage it is 
important to concentrate on the ''global modules'^ as opposed 
to *'detai 1 modules'* , For example you should be 
concentrating on "takes in the names of the students**, as 
opposed to, '*the steps necessary to tell the computer to 
take in the names** - It should not answer "how** , but should 
answer "what**. 

This stage is also where the development of **hidden modules*' 
are developed* "hidden modules'* are those modules which do 
not themsel ves produce a product whi ch can be vi ewed or 
heard, but are used to evaluate answers, involve decision 
branch i ng, or prBpar^ or transform i nf ormat i on for di spl ay 
or for further processing- An ©>iample might be an answer 
check ing routine whi ch woul d check a students answer to see 
if it were correct and then send i t to the proper subroutine 
based cn whether the answer was right or wrong* This routine 
would not really produce a product on the screen* but is 
very necessary to the successful completion of the narrative 
and the CAI* 

It is also the stage where debugging routines for later use 
can b© designed to simpify debugging once the program has 
been encoded. For example each module should have an 
Identifying number or letter so problems can be traced- It 
IS also a good idea to place frame numbers on the screen 
;^hen each frame is displayed so problems in various frames 
can be easily traced through the listing- By designing a 
system of debugging such as using a variable such as dt for 
di^fbuggi n<3 trace at the beginning of the program being 
devf^loped^ and placing a statement such as 10 IF DT^^^l THEN 
HTAB 3S:VTAB 24; PRINT "DT«J*\ This can save many hours 
later, just as all t^ e designing phases of CAI development. 

Fol 1 owi ng (fiodul ar i sat i on the author wi 1 1 have accumul a ted a 
wr i t ten 1 i at of the necessary modules to cause the narrat i ve 
to occur. It then becomes nece*5sary to sequence these 
modulfe?*=^ through flow charting- 

FLOW CHARTING involves the designing of the relationship of 
iBiMh of the modules to each other- It necessarily involves 
/nore detail than the modularization of the narrative* since 
1 1 incl udes the division of the narrat i ve modules i nto 
functional sub--modules which prepare or alter information in 
prf?paration for the ne^t module. Emphasis is on the 
relationship and sequence of each module to other modules as 
opposed to thfi? overall process of a module. 
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Each of the? modules should be labeled for easy tracing later 
and shoul d be con si stant 1 y carr ied throughout the 
development and encoding process. Otherwi se when debuggi ng 
it will be more difficult to trace a problem to the proper 
module. 

The f 1 ow chart shoul d be a graph i c representation showi ng 
the rel at i onshi p of the var i ous modules to each other ^ 
however a detai ied descr i pt i on of the f unct i on of each 
module should be written at this stage to be used by the 
author in later program<ra ng- Without a flow chart and a 
de^cr i pt i on of each of the f unct i ons each module 
accomplishes the author is likely to become confused when 
later programming each module. This stage is also important 
if another person is going to be doing the programming of 
the CAI. It provides him a guide for encoding the various 
f unct i ons. 

Fal 1 owi ng f low chart i ng a 1 i st of al 1 the modules^ in the 
proper sequence and with the proper sub-^modules will be 
di spl ayed schemat i cal 1 y and descr i bed verbal 1 y in wr i tten 
fci ready for blueprinting- 

Phase III: BLUEPRINTING 

Bl uepr i nt J ng i nvol ves the development of a detai 1 ed 
description of the CAI from frame to frame and function to 
f unct i on - It is the 1 ast phase where the descr i pti ons are 
not mach i ne sped f i c , i ^ e- ' f ol 1 owing this stage all desi gn 
wi 1 1 oni y work on a cer tai n computer and may not be readi 1 y 
changed to another machine. 

Bluepr i nt i ng i nvol ves two stages of development in this 
modul e: Frame devel op men t ^ and ? frame desl gn • 

FRAME DEVELOPMENT refers to the functional isati on of the 
tern modul es- Th i s i nvol ves deter ml nat i on of what 
^uficti ont^ have to occur f or each modul e i n order for it to 
carry out its^ function. Emphasi ^ i s on detai 1 sub-modules 
specific in f unct ion • This stag© also Involves the 
ama Igamati an of the content into th© function of the 
modul es, i • e:;* the content of each frame will necessar 1 1 y be 
matched with specific modul ©s f or thei r di sp 1 ay- £ar 1 i er 
emphasis was concerned with designing a module which would 
di spl ay the content * Now we are concerned with what modui es 
will be needed to display each frame:, well as what frames 
are needed , and i n what sequence for each f rame- 

A distinction needs to be made here concerning the 
modularization stage and the frame development stage. The 
modularization stage concentrates on the tasks to be 
completed to get the Ctar ratve ac compl i shed ^ whereas the 
frame development phases concentrates on accomplishing the 
^iecfciv^ through the presentation of the content. The 
f r ame development stage should invol ve a brief wri t ten 
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description of each o-f the various -frames ©elected for the 
CAI, and should be written as if the author was expecting 
another person to program the frame, which means al 1 the 
detail necessary to get the message across must be included- 
The frames shaul d be numbered accordi ng to the pi anned 
sequence. 

It is al SD in thi s phase where the speci f i c pre /post -test 
analysis is developed and treated much like the other frames 
within the CAI program- It should be designed so as to allow 
the student who has demonstrated, through pre-test^ he has 
accomplished an objective, to pass by instruction dealing 
wi th the ob j ecti ves he has already accompl i shed<r 

The post-test should provide information to the student 
concerning his status on the test and what he needs to work 
on i n order to successful 1 y compl ete the post^-test 
the ne>; t ti me. If the CAI you are develop! ng will al so keep 
records of students progress^ then this will also need to be 
taken i nto consi derat i on at thi s stage^r 

FRAME DESIGN refers to the actual 2--dimensional design, on 
paper, of the frame which wi 1 1 appear on the screen, hence a 
"blueprint^' to guide the programmer is developed for each 
screen . It is i mpor tant i n thi s phase to be aware of the 
various learning theories affecting the display and 
presentation of material to the student target population^ 
An understanding and familiarity with 2*-*dl mensi onal design 
theory is also important, in that the way you layout the 
screen may determi ne the successs of your CAI . 

In this stage it is also important to be aware of the 
characteristics of the computer you plan to use so you may 
1 n corporate the var i ous sens© generati ng devi ces aval 1 abl e 
on the computer you choose. Far e>^ ampl e a computer wh i ch 
does not have sound should not be chosen for a CAI program 
which teaches music. 

Frame desi gn is acompl i shed by usi ng story boards to di sp 1 ay 
drawings of how the frames will appear when completed. Story 
boards are drawings*, in sequence* of the various displays 
which will be presented on the screen^ They allow the author 
to view how the screen will appear before coding and 
thereby easily alter any frame deemed necessary without 
r ^proqr ammi ng the computer . Ideas can be gathered by 
/i£?wing other software and determining how effective their 
-f r ames seem to be , 

It is suggested al 1 frames be di vi ded into var i ous 
f unc ti onal areas so students wi 1 1 not be confused as they 
move from frame to frame throughout thts CAI. One art=fa of the 
screen may be reserved far directions* another for 
instructions and perhaps another for titling so the student 
wi 1 1 be aware of thei r posi tion wi thin the CAI. 
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Many computer publ i shers of f er worksheets'* to assi st in the 
design of frames. The worksheets are layout sheets with the 
necessary di spl ay i nf ormat i on pr i nted on them and all ow the 
author to desi gn and record important i nf or mat ion speci f i c 
to each frame on each war ksheet , simpl if yng the desi gn and 
recordi ng of organ i zat i onal i i format i on. The worksheets have 
a screen drawn on them in which the dimensions have !:he same 
rel ati onshi p as the actual computer screen, thereby 
allowing the author to view and make changes on a "screen" 
very similar to the computer screen before being coded into 
the computer , where change i s much more difficult to 
accompl i sh , 



Phase IV: CAI Synthesis 

CAI Synthesis refers to the actual encoding of the computer^i 
and once the author begins in this stage the CAI becomes 
machine specif icj i -e* it is written to c\ /<trol one 
computer- There are three stages in CAI Synthesis: Encodings 
Debuggi ng^ and!t Eval uation. 

ENCODING is the process of programming a specific computer 
to accompl ish the various tasks described earl ier- The 
encodi ng should incl ude remark statements to assi st i n 
debugging or updating the program at a 1 ater date, and 
should follow the blueprint developed earlier,, 

Encoding begins by taking the blueprint and programming each 
module of the program to accompHsh the results described by 
the blueorint. It is important to follow the blueprint as it 
provides the dec i si on information for deter mi ni ng the 
completion of encoding for each frame and eventually each 
module. 

It should also be remembered to incorporate the debugging 
rout i nes ment i oned earl i er into the encodi ng to simplify 
"debugging in the ne?<t stage- It becomes very difficult in a 
1 ong program to determine your 1 ocation wi thi n a 1 i sting 
once you have spotted a program error unless you have 
I abel ed each frame and used remark statements throughout 
your programming which matches the labels printed on each 
frame- 

As each module is completed;. if possibl*-*^ it should be 
tested for e?rrors and these corrected- Once the compl ste 
progr amm has been encoded you are ready to debug the 
program, 

DEBUGGING refers to the identification and correction of 
error ^5 ei ther programming, logic , or typographi cal error©- 
Xt is accompl i shed by running the CAI through all the 
possible branching routines and determining if there are any 
errors^ Almost all CAI programs will have errors in them 
t^hen they are first encoded because of the demanding detail 
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of instructions which computers require in order for them to 
carry out various fcasks.r Therefore it is very important ance 
you have debugged the program ir that you have other peopl e 
try the program so they may di scover bugs whi ch you have 
missed- It is even a good idea to pilot test the CAI before 
putting it in full use. Many problems can be caused by not 
properly testing CAI before placing it in full use. 

EVALUATION refers to the critiquing of the program by the 
author and other coi 1 agues to determine its'* success in 
accompi shi ng the ob jecti ves devel oped i n the f i rst phase. 
Suggestions may range from changes i n screen design^ to 
changes in frame layout and instructional presentation. 

It becomes very difficult to change a CAI program at this 
St age ^ and because of thi s al 1 efforts shoul d be taken to 
correct or alter CAI before reaching this stage. This may 
involved the opinion of other collegues during each stage of 
development. 

Generally when evaluating a program it is a good idea to 
check for spel 1 i ng error mi ssi ng f r ames^ poor 1 y designed 
frames, illogical frames and instructional weaknesses.r It is 
best to make notes concerning these errors, recording the 
frame number and the error whi ch you not iced, then going 
back into the listing to make the necessary changes. 

After connpletion of this phase all that is left to be 
compl eted is the Documentati on Development . 

Phase V: Documentation Development 

The Documentation Devel opment Phase in vol ves the devel opment 
of manuals, and other technical data for the use of the CAI. 
It involves the listing of system requirements and 
d<-:?vel opment of a manual - 

SYSTEM REQUIREMENT refers to the listing of the necessary 
hardware requirements at the beginning of the CAI as to 
al low the user to acquire the necessary equipment before 
using the CAI, Thi should also be included in the CAI 
instructional manual - 

Gtsneral ly^ the i nf ormat i on included in ^ stem requirements 
i ncl udes; Type of computer amount of storage capaci ty 
n<?eded^ necessary peripherals and input devices- It miqht 
also inform the user of specific requirements when 
-esponding to the CA I .r 

MANUAL DEVELOPMENT refers to the devel opment of a manual 
which describes the systfe,<T* requirements of the CAI^ as wel i 
as the instructions for the CAI use- It should be written 
keeping the user in mind and use schematics whenever they 
might simplify explanations concerning the CftI, 
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The blueprint should be used as a guide for describing the 
procedure for using the CAT. It i&hould start with 
instructions for loading the progrm into the computer and 
tlien proceed through the program explaining what occurs at 
each stage- It shoul d al so ment i on any speci f i c 
peculiarities of the program and contain a list of keywords^ 
i f appropr i at 65 used wi thni n the program. 

The manual should be divided according to the functions 
within the program so the user will not have to read the 
whole manual to find the answer to a specific question he 
may have concerning a certain function. The explanations 
should avoid Computer jargon and be written in plain English 
wi th an einphasi s on understanding « 



Summary 

Thi s then is a suggested model for Computer Assi sted 
Instruction- It incorporates the designing stategies of the 
engi neer and the i nst ruct i onal strategi es of the c 1 assroom 
teacher J as well as encoraging the use of layout^ 
instructional ^ and engineering design theories- As was 
stated earlier^ a perfect model for designing CAI does not 
e^^istfl but hopefully by continuing to improve on the various 
model s of CAI design and incorporating more and more of the 
skills from recognized areas complementing the design of 
CAI J we wi 1 ] come cl oser and cl oser to perf ect i on and 
ef f Qct X veness in the devel opment of Computer Assi sted 
Instruct i on - 

Computer Assisted Instruction is not the answer to every 
i nst rue ti onal probl em, and just as other methods may be 
appropr i ate for a part i cul ar i nstruct i onal task, and 
audio/visual tools must be carefully matched with objectives 
so must the computer- Like film^ talevisi on and all 
audi ovi sual aids computers can make i nst ruct i on moro 
ef f i ci ent , ef f ect i ve and mot i vat i ng, but onl y when used 1 n 
an I nf ormed and i nstruc t i onal 1 y sound way whi ch takes 
advantage of its'* posi t i ve characteri st i cs- There are t i mes 
when computers are i nef f ect i ve and we need to 1 earn to 
rt?cogni ze thi s f act , The computer i s sioipl y another book on 
the sh£?lf of the library of instructional methods. To be 
ef f act i ve i t must be chosen to answer the r i ght quest i on ^- 
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